
            <!DOCTYPE html>
            <html lang="en">
            <head>
                <meta charset="UTF-8">
                <title>监控系统 Prometheus 和 Zabbix 对比</title>
            </head>
            <body>
            <a href="https://andyoung.blog.csdn.net">原作者博客</a>
            <div id="content_views" class="markdown_views prism-atom-one-light">
                    <svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
                        <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path>
                    </svg>
                    <p>新公司要上监控，面试提到了 Prometheus 是公司需要的监控解决方案，我当然是选择跟风了。</p> 
<p>之前主要做的是 Zabbix，既然公司需要 Prometheus，那没办法，只能好好对比一番，了解下，毕竟技多不压身。</p> 
<p><img src="https://i-blog.csdnimg.cn/blog_migrate/236579a0e61c578fb81be594ba981916.png" alt="图片"></p> 
<p>但稍稍深入一点，我就体会到了 Prometheus 的优点，总结一下这两种监控方式。</p> 
<h4><a id="_8"></a>两种监控工具的历史简介</h4> 
<p><strong>Prometheus</strong></p> 
<p>Kubernetes 自从 2012 年开源以来便以不可阻挡之势成为容器领域调度和编排的领头羊。</p> 
<p>Kubernetes 是 Google Borg 系统的开源实现，于此对应 Prometheus 则是 Google BorgMon 的开源实现。</p> 
<p>Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库。</p> 
<p>从字面上理解，Prometheus 由两个部分组成，一个是监控报警系统，另一个是自带的时序数据库（TSDB）。</p> 
<p>2016 年，由 Google 发起的 Linux 基金会旗下的原生云基金会（Cloud Native Computing Foundation）将 Prometheus 纳入其第二大开源项目。</p> 
<p>Prometheus 在开源社区也十分活跃，在 GitHub 上拥有两万多 Star，并且系统每隔一两周就会有一个小版本的更新，而 Prometheus 与它的“师兄”Kubernetes 都自带云原生的光环，天然能够友好协作。</p> 
<p><strong>Zabbix</strong></p> 
<p>Zabbix 官方的发行版本时间可以追朔到 2012 年，时间上比 Prometheus 早了四年。</p> 
<p>Zabbix 是由 Alexei Vladishev 开源的分布式监控系统，是一个企业级的分布式开源监控方案。能够监控各种网络参数以及服务器健康性和完整性的软件。使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。</p> 
<p>这样可以快速反馈服务器的问题。基于已存储的数据，提供了出色的报告和数据可视化功能。</p> 
<h4><a id="_32"></a>架构对比</h4> 
<p><strong>Prometheus</strong></p> 
<p><img src="https://i-blog.csdnimg.cn/blog_migrate/239c087178240d0f3ca2252054752a38.png" alt="图片"></p> 
<p>Prometheus 的基本原理是通过 HTTP 周期性抓取被监控组件的状态，任意组件只要提供对应的 HTTP 接口并且符合 Prometheus 定义的数据格式，就可以接入 Prometheus 监控。</p> 
<p>Prometheus Server 负责定时在目标上抓取 Metrics（指标）数据并保存到本地存储里面。</p> 
<p>Prometheus 采用了一种 Pull（拉）的方式获取数据，不仅降低客户端的复杂度，客户端只需要采集数据，无需了解服务端情况，而且服务端可以更加方便的水平扩展。</p> 
<p>如果监控数据达到告警阈值 Prometheus Server 会通过 HTTP 将告警发送到告警模块 alertmanger，通过告警的抑制后触发邮件或者 webhook。</p> 
<p>Prometheus 支持 PromQL 提供多维度数据模型和灵活的查询，通过监控指标关联多个 tag 的方式，将监控数据进行任意维度的组合以及聚合。</p> 
<p><strong>Zabbix</strong></p> 
<p><img src="https://i-blog.csdnimg.cn/blog_migrate/d8da2f22f33ff9ebd5374c2fc8a68ad3.png" alt="图片"></p> 
<p>Zabbix 由 2 部分构成，Zabbix Server 与可选组件 Zabbix Agent。Zabbix Server 可以通过 SNMP，Zabbix Agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能。</p> 
<p>它可以运行在 Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OS X 等平台上。</p> 
<p>核心组件主要是 Agent 和 Server，其中 Agent 主要负责采集数据并通过主动或者被动的方式采集数据发送到 Server/Proxy，除此之外，为了扩展监控项，Agent 还支持执行自定义脚本。</p> 
<p>Server 主要负责接收 Agent 发送的监控信息，并进行汇总存储，触发告警等。</p> 
<p>Zabbix Server 将收集的监控数据存储到 Zabbix Database 中。Zabbix Database 支持常用的关系型数据库，如果 MySQL、PostgreSQL、Oracle 等，默认是 MySQL，并提供 Zabbix Web 页面（PHP 编写）数据查询。</p> 
<p>Zabbix 由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘。</p> 
<p>所以从 Zabbix 4.2 版本后开始支持 TimescaleDB 时序数据库，不过目前成熟度还不高。</p> 
<h4><a id="_66"></a>综合对比</h4> 
<p><img src="https://i-blog.csdnimg.cn/blog_migrate/a41f1abf43b174b8a607362ce2e5b2e4.png" alt="图片"></p> 
<p>上面的表格，从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从 C 语言转移到 Go。</p> 
<p>不得不说，Go 凭借简洁的语法和优雅的并发，在 Java 占据业务开发，C 占领底层开发的情况下，准确定位中间件开发需求，在当前开源中间件产品中被广泛应用。</p> 
<p>从系统成熟度上看，Zabbix 是老牌的监控系统：Zabbix 是在 1998 年就出现的，系统功能比较稳定，成熟度较高。</p> 
<p>而 Prometheus 是最近几年才诞生的，虽然功能还在不断迭代更新，但站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验。</p> 
<p>从数据存储方面来看，Zabbix 采用关系数据库保存，这极大限制了 Zabbix 采集的性能，而 Prometheus 自研一套高性能的时序数据库，在 V3 版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储。</p> 
<p>从配置复杂度上看，Prometheus 只有一个核心 server 组件，一条命令便可以启动，相比而言，其他系统配置相对麻烦。</p> 
<p>从社区活跃度上看，目前 Zabbix 比较活跃，但基本都是国内的公司参与，Prometheus 在这方面占据绝对优势，社区活跃度虽然不如，但是受到 CNCF 的支持，后期的发展值得期待。</p> 
<p>从容器支持角度看，由于 Zabbix 出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。</p> 
<p>而 Prometheus 的动态发现机制，不仅可以支持 Swarm 原生集群，还支持 Kubernetes 容器集群的监控，是目前容器监控最好解决方案。</p> 
<h4><a id="_88"></a>总结</h4> 
<p>综合来看，Zabbix 的成熟度更高，上手更快，但更好的集成导致灵活性较差，问题更大是，监控数据的复杂度增加后，Zabbix 做进一步定制难度很高，即使做好了定制，也没法利用之前收集到的数据了（关系型数据库造成的问题）。</p> 
<p>Prometheus 基本上是正相反，上手难度大一些，但由于定制灵活度高，数据也有更多的聚合可能，起步后的使用难度远小于 Zabbix。</p> 
<p>但如果已经对传统监控系统有技术积累的话，还是要谨慎考虑更换监控。</p> 
<p>如果监控的是物理机，用 Zabbix 没毛病，Zabbix 在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。</p> 
<p>甚至环境变动不会很频繁的情况下，Zabbix 也会比 Prometheus 好使；但如果是云环境的话，除非是 Zabbix 玩的非常溜，可以做各种定制，否则还是 Prometheus 吧，毕竟人家就是干这个的。</p> 
<p>Prometheus 开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。</p> 
<p>如果是刚刚要上监控系统的话，不用犹豫了，Prometheus 准没错。</p>
                </div>
            </body>
            </html>
            